Everything hsc knows about html, it retrieves from a file named hsc.prefs at startup. This file contains information about all tags, entities and icon entites. Additionally, some special attributes are set up there also.
The main advantage of this concept is that it's rather
easy to add new syntax elements. For this task, the hsc tags
<$deftag>, <$defent> and <$deficon> can be used.
It is a serious problem about html that no one can give you competent answer on the question ``Now which tags are part of html?''. On the one hand, there is w3c, which you meanwhile can ignore, on the other hand, there are the developers of popular browsers, which implement whatever they just like.
The hsc.prefs coming with this distribution should support most elements needed for everyday use. This includes full html-2.0-support, tables, client-side image-maps and several elements only used by special browsers.
However, they are currently rather outdated and could need a major rework. This should come with one of the next releases.
PROGDIR:, which is automatically
assigned to the same directory where the hsc binary resides
when hsc is invoked
If it is unable to find hsc.prefs anywhere, it will abort with an error message.
If you want to find out where hsc has read hsc.prefs from, you can use STATUS=VERBOSE when invoking hsc. This will display the preferences used.
This tag defines
a new entity. The (required) attribute NAME declares the
name of the entity, RPLC the character that should be
replaced by this entity if found in the hsc-source and NUM
is the numeric representation of this entity.
<$defent NAME="uuml" RPLC="ΓΌ" NUM="252">
This tag defines
a new icon-entity. The only (required) attribute is NAME
which declares the name of the icon.
<$deficon NAME="mail">
This tag defines
a new tag, and is used quite similar to <$macro>, exept that a
tag-definition requires no macro-text and end-tag to be followed.
<$deftag IMG SRC:uri/x/z/r ALT:string ALIGN:enum("top|bottom|middle") ISMAP:bool WIDTH:string HEIGHT:string>
To fully understand the above line, you might also want to read the sections about attributes and options for tags and macros.
For those, who are not smart enough or simply to lazy, here are some simple examples, which should also work somehow, though some features of hsc might not work:
<$deftag BODY /CLOSE BGCOLOR:string> <$deftag IMG SRC:uri ALT:string ALIGN:string ISMAP:bool>
DTD is short for Document Type Definition. One of the early concept of html was that the first line of a document should contain a line that tells which DTD has been used to create this document. This could look like
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
Browsers should read that line, obtain the DTD and parse the source according to it. The problem about DTDs: they are written in sgml. And the problem about sgml: It's awful. It's unreadable. It's a pure brain-wanking concept born by some wireheads probably never seriously thinking about using it themselves. Even when there is free code available to sgml-parse text.
As a result, only less browsers did support this. As it was rather easy to write a browser spiting on the sgml-trash, but simply parsing the code ``tag-by-tag'', developers decided to spend more time on making their product more user-friendly than computer-friendly (which I really can understand).
These browsers became even more popular when they supported tags, which certain people liked, but were not part of DTDs. As DTDs were published by w3c, and w3c did not like those tags, they did not made it into DTDs for a long time or even not at all (which I really can understand, too).
This did somehow work until html-2.0. Several people (at least most of the serious w3-authoring people) did prefer to conform to w3c than use the funky-crazy-cool tags of some special browsers.
However, after html-2.0, w3c fucked up. They proposed the infamous html-3.0 standard, which was never officially released, and tried to ignore things most browsers did already have implemented (which not all of them were useless). After more than a year without any remarkable news from w3c, they finally canceled html-3.0, and instead came out with html-0.32.
Many people were very happy about html-0.32, as it finally was a statement after that many things became clear. It became clear that you can not expect anything useful from w3c anymore. It became clear that the browser developers had won. It became clear that no one is going to provide useful DTDs in future, as browser developers are too lazy to do that. It became clear that anarchy has broken out for html specifications.
So, as a conclusion, reasons not to use DTDs but an own format are:And, if you take a look at the current activities of w3c (discussing a standard for frames or proposing XML) and browser developers (spending most of their time fixing security bugs or write the ultimate desktop interface for all computers ever), I consider this even more a reasonable decision.
There is also a disadvantage of this concept: reading hsc.prefs every time on startup needs an awful lot of time. Usually, processing your main data takes shorter than reading the preferences. You can reduce this time, if you create your own hsc.prefs with all tags and entities you don't need removed. But I recommend to avoid this because you might have to edit your preferences again with the next update of hsc, if any new features have been added.